Improving Performance

    Why improve performance?

    Supporting all the modern features of the web is a demanding business, with all manner of fonts, images, animation, flash movies, dynamic content and more all taking a sizable chunk of your computer's abilities. This is compounded by the fact that data transfer from the web (even with broadband) seems to lag behind what people try to put out there (more pictures, more animations, more movies and so on)! As such, a web browser has to ride a tough line to try and deliver the best experience to the user.

    To further add to the problem, a RISC OS browser has to run on a huge range of machines, from a 4Mb A3010 (yes, people do still use such machines) to the latest StrongArm or Xscale machines! To ensure that the software works "out of the box" on all machines, we have made many aspects optional, and hence there are many ways in which performance can be improved.

    Font cache

    On many occasions people have commented that WebsterXL seems to render text more slowly than other, simpler browsers. What they forget is that WebsterXL has a much greater understanding of Font Faces than other RISC OS browsers, and as such will often be using far more typefaces on screen. If you haven't told your RISC OS machine to reserve memory for fonts, then this will be slow! This applies to all RISC OS applications using lots of fonts.

    To quickly check how much font memory is configured on your machine, left-click on the RISC OS 4 cube (or Acorn icon) in the bottom right hand corner of the screen. Scroll down to the System memory allocation section and look for the Font cache line. If this is less than about 512kb then it is likely to be a problem. At the time of writing this RiscPC is has 412kb of fonts in memory, and the machine hasn't yet been used online (it has been used to view a normal DTP document and the WebsterXL documentation). Many RISC OS machines default to just 64Kb of Font cache, so you can see that it is highly likely that you would run out! For a "quick fix" simply drag the Font cache bar out to allocate more memory.

    A more permanent solution is to double click on !Boot on your hard disc, and go to the Font configuration tool. At the bottom of this window you can set the font cache size. Don't rely on the "No font cache limit" option - make sure the initial font cache size is 512Kb or higher. Note that if your computer has 8Mb of RAM or less, you might wish to choose a smaller value, perhaps 256Kb.

    With a healthy Font cache, WebsterXL will be able to use a variety of fonts at all manner of sizes, without major speed penalties

    RAM Disc vs Hard Disc

    In order to overcome the slow speeds of download of data from the web, many web browsers use a disc cache - a store of recent data on your computer's hard drive. Whilst a hard drive runs many times faster than web downloads, most RISC OS machines are plagued by slow and in-efficient hard drive technologies compared to their Windows brethren. Whilst the latest RISC OS machines such as the Omega and the Iyonix are alleviating this, the fact remains that the hard disc is often a bottleneck on RISC OS machines. Indeed, some browsers have opted not to cache data at all, rather than use slow RISC OS hard discs!

    WebsterXL has always been designed to use a cache, because doing so is advantageous for saving etc. However, RISC OS offers another type of "drive" that is many times faster - the RAM Disc. RAM discs use a block of main system memory as a very fast drive, but the contents are lost at power-off. We have built facilities into WebsterXL to make use of RAM discs to significantly improve performance - fetching average pages can be 3-4 times faster! However, to accommodate low spec (4Mb) machines, we have disabled these facilities by default, so you will probably want to enable them!

    Firstly, you should not enable any form of RAM caching if you have less than 8Mb of memory - your machine will need all the memory it can get for other purposes. Secondly, WebsterXL has two levels of RAM cache - just temporary files, or the whole cache. There is no downside to having temporary files use a RAM disc, and you will see a noticeable speed up by enabling this. It will use about 256Kb of RAM for RAM disc, making it ideal for machines of 12-32Mb (and higher too!). Since the RAM disc is so much faster, WXL will seem much more responsive. The second level of caching (full RAM cache) is really only recommended for machines with more than 32Mb of RAM, as it really requires 10+Mb of RAM disc. The disadvantage compared to using a hard disc is that the contents of the cache are lost at power-off, but the speed benefit is significant!

    To enable RAM caching, press the Menu mouse button over the WebsterXL icon on the iconbar. Go off Configure -> Browser and click on that entry. The WebsterXL configuration window appears. On the first page displayed, you will see four Entries concerned with RAM cache:

    • Use RAM disc for Temporary files
    • Use RAM disc for Cache
    • Empty RAM disc on Exit
    • RAM Disc Cache Size (MB)
    Assuming that you have more than 8Mb of RAM, enable RAM disc for Temporary files! You may also wish to tick the Empty on Exit option, in which case WebsterXL will tidy up after itself.

    If, after reading the above paragraphs, you wish to enable RAM caching, tick the Use RAM for Cache option. You can then adjust the size of cache in the entry below. We suggest 10Mb (the machine being used has it set to 12Mb).

    Once you have made your selection, click the Save button. You will need to quit and restart WebsterXL for these changes to take effect.

    Redraw interval

    When rendering a page, WebsterXL makes a trade-off between the speed at which it updates the screen to reflect how far it is progressed, and rendering more. For example, if Webster is updating the screen very frequently, it will be spending less time decoding the page, and therefore the total time to render a page will be longer - it will feel smoother, however, as the screen is updating more quickly. On the reverse, if Webster doesn't update the screen at all whilst calculating, the total time will be reduced, but the software will appear much less responsive when rendering. Again, this is a problem faced by any application which is rendering data to screen whilst also processing/calculating.

    The logical conclusion is to pick a balance of responsiveness and overall time. Whilst we have done a fair bit of testing to find a good balance, you may wish to adjust this. To do so, press the Menu mouse button over the WebsterXL icon on the iconbar. Go off Configure -> Browser and click on that entry. The WebsterXL configuration window appears. Select the Decoding option down the right hand side, and you will see the top option reads: Multitask while loading       Interval 10

    If you adjust the interval down, WebsterXL will become more responsive. If you increase it (or turn the option off altogether), the total time to render the page will be decreased, but the software will appear much less responsive. Try it and see.

    Dealing with small backgrounds

    Some web sites use very tiny background graphics (1 or 2 pixels in size!) and tiling these over the background of a page can consume a fair slice of computer performance. The RISC OS window manager is quite inefficient in its handling of such images. To get round this, WebsterXL can tile them internally up to a sensible size, before passing over to the Window manager. This needs a small amount of RAM, but can give a significant performance boost on affected pages. You will almost certainly want this enabled (it should be by default).

    To check that this is enabled, press the Menu mouse button over the WebsterXL icon on the iconbar. Go off Configure -> Browser and click on that entry. The WebsterXL configuration window appears. Go to the Window section, and make sure Multiply small backgrounds is enabled. Click Save once done.

    Enabling or disabling options

    WebsterXL attempts to handle many aspects of the web, but of course, the more features and facilities you handle, the more processing is required, and the more performance can be reduced. On higher specification machines, we would obviously recommend running with most, if not all, the options enabled. However, if you are trying to squeeze more performance out of a lower or mid-range machine, there are many things you can try...

    Start by pressing the Menu mouse button over the WebsterXL icon on the iconbar. Go off Configure -> Browser and click on that entry. The WebsterXL configuration window appears.

    Select the Decoding option down the right hand side. There are a number of options here. Perhaps the most drastic is "Decode HTML Extensions" - turning this off will disable many browser facilities, and is probably overkill on all but the most basic of machines. Next comes Display tables. Tables are used on many web sites, often for complex layouts where tables will exist within tables, within tables, in cells linked to cells which contain other tables... and so on. Tables eat a LOT of processing time, and disabling them will give a major performance boost. However, doing so will result in many sites rendering incorrectly...

    Further down the list, you will see the Obey Font Sizing option. This (and the associated font colours option in the Colours window, described later) affect how many font styles and variations will be used/remembered on your machine. We have seen some instances (for example, a giant [really giant!] train-timetable which set font sizes, faces, colours for each individual table cell) where this had a significant effect on the overall time to render, because of all the extra work being done. However, in most cases this option will not give significant improvements.

    Lower down, you will see Display frames, Display Plugins and Display IFrames. Frames are a layout aid, and don't impact browser performance in any significant way. Plugins expand browser functionality, but can be very slow - if you are on less than a StrongArm machine, we suggest disabling plugins. IFrames are almost universally used for advertising banners (what a waste of a technology!) and are therefore worth disabling!

    Finally on this section of the configuration, we have Style sheets. Style sheets are files or code which describe how different parts of the page should be rendered. If WebsterXL renders pages with style-sheets, you will often see improved font/colour rendering. However, because the styles have to be processed, we recommend turning them off on lower specification machines, as the benefits are usually not earth-shattering.

    Moving on to the Images section down the right-hand-side, there are four tick-boxes determining how WebsterXL handles images. In most cases, you will wish to enable both background images, and images on the page, as sites will look odd without. Whilst there is a performance benefit to be had by turning them off, it is a sacrifice that most will not wish to make (unless you are running on a very tiny amount of memory).

    Table and Cell backgrounds, on the other hand, may well be worth experimenting with. These options are usually disabled by default, as they involve WebsterXL tiling background images (in memory) for table cells, and whole tables. This can be quite memory intensive, and both should be disabled on 16Mb or less. If enabled, they will often improve the visual look of the page, but be aware that tiling small backgrounds up to cover large tables can take some time - you may see the machine pausing to fill in the background of large tables. Cell backgrounds generally pose less of a performance hit than table backgrounds.

    Moving down to the Colours section, disabling colour changes may give a little extra performance. Clearly this will affect the look of the page, but some people prefer to pick their own colours, rather than having a web author pick a garish colour-blind scheme!

    This leaves us with the Script section. JavaScript should be disabled on machines below RiscPC specification, because it is a programming language (akin to C++) which is executed by the browser in real-time. Low spec machines simply do not have the number-crunching power to handle this. Even StrongArm machines can slow down when executing JavaScript. JavaScript is used by many sites these days, and when used correctly shouldn't be a problem. However, there are many web designers who value whizzy real-time effects over usability, and that's where the problems start. As such, there are times when you will want to disable JavaScript.

    Comparing performance

    Is your machine performing as well as it could be? On a Kinetic RiscPC, this page renders in approximately 1.15 seconds (look at the grey bar at the bottom of the page - it should show the time taken to render). Right now, it has actually taken 1.14 seconds. The default Home page (the one that appears when you first load !WebsterXL) renders in 0.83 seconds first time, and 0.37 seconds on a refresh.

    A standard SA RiscPC with slow hard disc gives 1.42 seconds for the home page (0.59 for refresh) and 1.96 seconds for a this performance page.

    At the other end of the spectrum, the Iyonix opens the default home page in 0.49 seconds (first time load) and refreshes in 0.31 seconds. This performance page takes 0.83 seconds.

    There are many factors at play here - speed of processor (the two machines are actually similar on this point!), speed of memory, speed of hard disc, speed of hard disc interface, font cache and so on. Also, remember that higher resolutions will run slower than lower resolutions. The numbers above were done at 1360x1024 in 256 colours.

    A technical way of boosting performance


    One way in which the Kinetic RiscPC boosts performance is to run the operating system modules out of RAM rather than slow ROM. Whilst you can't easily run the whole OS from RAM on older machines, you can force individual operating system modules into RAM. A special * command called *RMFaster is provided to do this. Whilst WebsterXL makes use of many operating system modules, you may find benefits to RMFaster-ing the following modules - WindowManager, BASIC, ColourTrans, FontManager. Some of the hard disc/IO modules may also benefit from this, but can be harder to RMFaster. As we said, this was a technical way of improving performance, so if you aren't sure about it, don't try.